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Abstract 

Assume-guarantee reasoning is a popular and expressive paradigm for modular and composi- 
tional specification of programs. It is becoming a fundamental concept in some computer-aided 
design tools for embedded system design. In this paper, we elaborate foundations for contract-based 
embedded system design by proposing a general-purpose module language based on a Boolean al- 
gebra allowing to define contracts. In this framework, contracts are used to negociate the correctness 
of assumptions made on the definition of a component at the point where it is used and provides 
guarantees to its environment. We illustrate this presentation with the specification of a simplified 
4-stroke engine model. 


1 Introduction 

Methodological common sense for the design of large embedded architectures advises the validation of 
specifications as early as possible, and further advocates for an iterative validation of each refinement or 
modification made to any component of the initial specification, until the implementation of the system 
is finalized. As an example, in a cooperative industrial environment, designers often use and assemble 
components which have been developed by different suppliers. These components have to be provided 
with conditions of use and need to offer pre- validated guarantees on their function or service. The con- 
ditions of use and the service guarantee define a notion of contract. Design by contract, as advocated 
in [23], is now a common programming concept used in general-purpose languages such as C++ or 
Java. Assertion-based contracts express program invariants, pre and post conditions, as Boolean type 
expressions that have to be true for the contract being validated. We adopt the paradigm of contract to 
define a component-based validation process in the context of an embedded software modeling frame- 
work. It consists of an algebraic framework, based on two simple concepts, enabling logical reasoning 
on contracts [11]. First, the assumptions and guarantees of a component are defined as devices called 
filters: assumptions filter the behaviors a component accepts and guarantees filter the behaviors a com- 
ponent provides. Filters form a Boolean algebra and contracts define a Heyting algebra. This yields a 
rich framework to abstract, refine, combine and normalize contracts. In this paper, we put this algebra to 
work for the definition of a general purpose module system whose typing paradigm is based on the notion 
of contract. The type of a module is a contract holding assumptions made and guarantees offered by its 
behaviors. It allows to associate a module with an interface which can be used in varieties of scenarios 
such as checking the composability of modules or efficiently supporting modular compilation. 

Plan We start with a highlight on some key features of our module system by considering the specifi- 
cation of a simplified engine controler. Section 2. This example is used through the article to illustrate 
our approach. We give a short outline of our contract algebra. Section 3, and demonstrate its capabilities 
for logical and compositional reasoning on the assumptions and guarantees of component-based embed- 
ded systems. Our main contribution, section 4, is to use this algebra as a foundation for the definition 
of a strongly-typed module system: contracts are used to type components with behavioral properties. 
Section 5 demonstrates the use of our module system by considering the introductory example and by 
illustrating the refinement mechanism of the language. We review related works. Section 6, before con- 
cluding, Section 7. 
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2 An example 


We illustrate our approach by considering a simplified automotive application presented in [4]. We 
define contracts to characterize properties of a four-stroke engine controller. In this specification, the 
cyclic behavior of the engine is rendered by four successive phases: Intake , Combustion, Compression, 
and Exhaust. These phases are driven by a camshaft whose angle is measured in degrees. This unit of 
measure defines a discrete and symbolic time sampling in the system. The angle of the camshaft marks 

an occurrence of a clock tick (the 
cam) at which sensors are sampled 
and a reaction is triggered. For exam- 
ple, at 90°, the intake valve is closed 
and a transition to compressin mode 
is triggered. 

In the module language, a specification is designated by the keyword contract. It defines a set of in- 
put and output variables subject to a contract. The interface defines the way the environment and the 
component interact through its variables. In addition, it embeds properties that are modeled by the com- 
position of contracts. For instance, the specification of the intake mode of the engine controller could be 
defined by the assumption o <= (cam mod 360) < 90 and the guarantee intake. An implementation of 
the interface, designated by the keyword process, contains a compatible implementation of the contract 
assigning true to the signal intake when o <= (cam mod 3 60) < 90. 



90 "CAM after 
—entering state 
Compression leave 
this state and enter 
state Combustion 


module type IntakeType = Module IntakeMode : IntakeType = 

contract process 

input integer cam; input integer cam; 

output event intake; output event intake; 

assume 0 <= (cam mod 360) < 90 intake := true when cam mod 360<90 

guarantee intake end; 

end; 

The specification of the properties we consider for the engine consists of four contracts. Each contract 
specifies a phase of the engine. It is associated to a position of the camshaft and triggers an event. 
Instead of specifying four separate contracts, we define them as four instances of a generic contract. 
To this end, we define an encapsulation mechanism to generically represent a class of interfaces or 
implementations sharing a common pattern of behavior up to that of the parameter. In the example of 
the engine, for instance, we have used a functor to parameterize it with respect to its angle position. 


module type phase = 

functor (integer min, integer max) 
contract 

input integer cam ; 

output event trigger; 

assume min <= (cam mod 360) < max 

guarantee trigger 


module type engine = contract 
input integer cam ; output event intake, 
compression, combustion, exhaust; 
phase (0, 90) (cam, intake) 
and phase (90, 180) (cam, compression) 
and phase (180, 270) (cam, combustion) 
and phase (270, 360) (cam, exhaust) 


end; end; 

The generic contract, called phase, is parameterized with a trigger and with camshaft angle bounds. 
When the camshaft is within the specified angles, the engine controller activates the specified trigger. 
The contract of the engine is defined by the composition “and” of four applications of the generic phase 
contract. Each application defines a particular phase of the engine with its appropriate triggers and 
angles. The composition defines the greatest lower-bound of all four contracts. Each application of the 
phase functor produces a contract which is composed with the other ones in order to produce the expected 
contract. A component is hence viewed as a pair M : I consisting of an implementation M that is typed 
by (or viewed as) an interface I of satisfiable contract. The semantics of the specification 7, written [[ 1 1| . 
is a set of processes (in the sense of section 3) whose traces satisfy the contracts associated with 7. The 
semantics [[ M || of the module M is the singleton containing the process [[IntakeMode || • 
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3 An algebra of contracts 

A contract is viewed as a pair of logical devices that filter processes: the assumption A filters processes to 
select (accept or conversely reject) those of which that are to be asserted (accepted or conversely rejected) 
by the guarantee G. A process p fulfils (A,G) requirements (satisfies (A,G)) if either it is rejected by A (it 
is then out of the scope of (A,G) contract), or it is accepted by A and by G. We have chosen to represent a 
filtering device (such as A or G) by a process-filter which is the set of processes that it “accepts” (i.e., that 
it contains). We give more details of the algebra of contracts, including examples, additional properties 
and formal proofs in a technical report [11]. In the remainder, we only define the mathematical objects 
that are relevant to the presentation of our module system. They consist of two relations in the contract 
algebra, noted =<! for refinement and JJ. for composition. In fact, our module system can be seen as a 
domain- specific language that syntactically reflects the structure of our contract algebra. 

For X a nonempty finite set of variables, a behavior is a function b : X — > ^ where is a set of 
values (that may be traces), and a process p is a nonempty set of behaviors defined on X. We denote 
by Q. — {0} the unique process defined on the empty set of variables: it has a single behavior that is 
the empty behavior. The set of processes is noted P; it is extented to P* by adding the empty “process ” 
noted U = 0. A process-filter R is the set of processes that satisfy a given property on a set of variables 
X; notice that if a process p is in R so are all processes defined on supersets of X, whose sub-behaviors 
restricted to X are behaviors in p; moreover if a process p is in R, so are all nonempty subsets of p. By 
convention, {15} is a process-filter. We define an order relation C on the set of process-filters <P extended 
by {15} and establish that (<£>,Q is a lattice. Also, (<£>,Q is a Boolean algebra with P* as 1, {15} as 
0. The complementary of R is noted R. The conjunction R n S of two process-filters R and S is the 
greatest process-filter T = RnS that accepts all processes whose behaviors are at once behaviors in 
some process accepted by R and behaviors in some process accepted by S. The process-filter disjunction 
R U S of two process-filters R and S is the smallest process-filter T = RUS that accepts all processes 
whose behaviors are at once behaviors in some process accepted by R or behaviors in some process 
accepted by S. A contract C = (A,G) is a pair of process-filters and C m <Px<P is the set of contracts. 
The refinement relation (=() is a partial order on contracts. (C, =<) is a distributive lattice of supremum 
({15}, P*) and infimum (P*,{15}): it is a Heyting algebra. We define the nominal contract /r B of a process 
p as the contract that assumes any behavior and guarantees all the possible behaviors of p. Two contracts 
Ci and C 2 have a greatest lower bound C| 1} C 2 and a least upper bound Ci j[ C 2 . The greatest lower 
bound C = (A,G) of two contracts Ci = (Ai,Gj) and C 2 = (A 2 ,G 2 ) is defined by: A = Aj U A 2 and 
G = ((Ai n a 2 n Gi) u (Ai n a 2 n g 2 ) u (Gi n G 2 )). 

4 A module language for typing by contracts 

In this section, we define a module language to implement our contract algebra and apply it to the 
validation of component-based systems. For the peculiarity of our applications, it is instantiated to 
the context of the synchronous language Signal, yet could equally be used in the context of related 
programming languages manipulating processes or agents. Its basic principle is to separate the interface, 
which declares properties of a program using contracts, and implementation, which defines an executable 
specification satisfying it. 

4.1 Syntax 

We define the formal syntax of our module language. Its grammar is parameterized by the syntax of 
programs, noted p or q, which belong to the target specification or programming language. Names 
are noted x or y. Types t are used to declare parameters and variables in the interface of contracts. 
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Assumptions and guarantees are described by expressions p and q of the target language. An expression 
exp manipulates contracts and modules to parameterize, apply, reference and compose them. 


x,y 

P,q 

b,c ::= event j boolean | short | integer 
t ::= b | input/? | output b \ x \ t x t 
dec ::=t x [, dec] 
clef ::= module [type]* = exp 
modulex [: t ] = exp 
def\def 


name ag 

process 

datatype exp 

type 

declaration 

definition 


[assume p\ guarantee q; 

ag and ag \ x(y*) 
contract dec, ag end 
process dec, p end 
functor (dec) exp 
exp and exp 
x (exp*) 
let def'm exp 


contract 

process 

contract 

process 

functor 

composition 

application 

scoping 


4.2 A type system for contracts and processes 

We define a type system for contracts and processes in the module language. In the syntax of the module 
language, contracts and processes are associated with names x . These names can be used to type formal 
parameters in a functor and become type declarations. Hence, in the type system, type names that stand 
for a contract or a process are associated with a module type T . A base module type is a tagged pair 
T (I,C). The tag T is n for the type of a process and y for the type of a contract. The set I consists of pairs 
x : t that declare the types t for its input and output variables x. The contract C is a pair of predicates 
(p,q) that represent its assumptions p and guarantees q. The type of a functor A(x : S).T consists of the 
name x and of the types S and T of its formal parameter and result. The role of the typing hypothesis Y 
is to hold an association x : T of names to types (we write T(x) the type of name x in V ). The role of the 
typing constraints £ is to register inferred refinement relations of the form CAD. 

S, T ::=f | t(/,C) | Sx T | A(x : S).T (type) T ::= y | K (kind) r::=0|rUx:T Y.::=Ql\Y.UC AD (context) 


4.3 Contract refinement 


We wish to define a subtyping relation on types t to extend the refinement relation of the contract algebra 
to the type algebra. In that aim, we wish to apply the subtyping principle S < T to mean that the semantic 
objects denoted by S are contained in the semantic objects denoted by T (S refines T ). Hence, a module 
of type T can safely be replaced or substituted by a module of type S. For example, consider a process P 
with one long input x and two short outputs a,b, and a process Q with two integer inputs x,y and one 
integer output, such that P refines 


(/.Then the type of a module M en- 
capuslating P is a subtype of a mod- 
ule N encapsulating Q. M can re- 
place N. 


x:long— > 

P 

^a:short xiinteger — > 

Q 



— >b:short — y:integer — ► 



?a: integer 


4.4 Subtyping as refinement 

Accordingly, we say that 5 is a subtype of t under the hypothesis £, written YZj s <t i IT £ contains (or 
implies) the relation s <t. The inductive definition of the subtyping relation < starts with the subtyping 
axioms for datatypes. Then, it is elaborated with algebraic rules, the rules for declarations and, finally, 
one rule for each kind of module type. In particular, a module type S—t(I, C) is a subtype of T — t(J, D), 
written £ D S < T, iff the inputs in J subtype those in I, if the outputs in I subtype those in J, and if the 
contract C refines D. In the rule for functors, we write V [y/x] for substituting the name x by y in V (we 
assume that y does not occur in V). 
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T <T event < boolean short < integer < long 

Ed b < c Ed b < c 

E D input c < input b Ed output b < output c 


Ed 7<7 x ^ vars(I) E D I <7 x ^ vars(J) 
E D I < (x : input b) U 7 E D (x : output b) U I < J 
t < y E D 7 < 7 (C ^ O) € E t<t' 
tr< T Ed t(/,C) < T'(y,D) 


eds<t t.dt<u 


L^S<U 


e D/< y t.ds<t 

Ed (x:S)U7< (x: T)U7 


I.DS<U T<V T,^U<S E D T < V[x/y] 
T.D SxT <U xV LDA{x:S).T<A(y:U).V 

Alternatively, we can interpret the relation £ D C A 7) as a mean to register the refinement constraint 
between C and /) in E. It corresponds to a proof obligation in the target language whose meaning is 
defined by the semantic relation [[C]] A [[£)]] in the contract algebra, and whose validity may for instance 
be proved by model checking. The set E of refinement relations CAD is obtained by the structural 
decomposition of subtyping relations of the form s < t into either elementary axioms, e.g. event < 
boolean, or proof obligations CAD. 


4.5 Greatest-lower and lowest-upper bounds 


Just as the subtyping relation, which implements and extends the refinement relation of the contract 
algebra in the typing algebra, the operations that define the greatest lower bound and least upper bound 
of two contracts are extended to module type by induction on the structure of types. The intersection and 
union operators are extended to combine the set of input and output declarations of a module. The side 
condition is that x ^ domiJ). 


t(7, C) n t( 7, D) =t (7 n 7, C JJ. D) 

S x T fl U x V=(5TI U) x {T n V) 
A(x:S).TnA(y :U).V=A(x: (5Uf/)).(TnF[y/x]) 
t(/,C) U t(7, D)=t( 7U7,C it-D) 

SxTUUx V=(SUU) x {T U V) 
A(xA).7’UA(y:l/)T=A(i:(Sni/)).(7’Uk[y/x]) 


(7 U (x : 5)) n (7U (x : T))=(7n7) U (x : Sn T) 

(7 U (x : S)) U (7U (x : T))=(7U7) U(x:XU7) 
(7U(x: input I>))n7=(7n/)W 0n7 = 0 
(7 U (x : output b) ) n J= (7 fl J) U (x : output b) W 
(7U (x : input b)) U/=(7U7) U (x : input b 
(7U (x : output h)) U/=(7U7)(*) 0U7 = 7 


4.6 Type inference in the module language 


Our aim is to check the correctness of program construction. Hence, type inference shall produce a 
consistent type assignment to contract and process names in the module language and generate a proof 
obligation in the form of an observer function [12] (used for describing some properties) in the target 
programming language. The type inference system is defined by the sequent T/E b exp where Y is the 
typing environment, E the typing constraints and exp is an expression of the module language. It embeds 
the type system of the target language: we assume that the relation Y b p tells that p is well-typed in 
the target language under the hypothesis T. The sequent establishes a structural correspondence between 
expressions and types. It is defined by induction on the structure of expressions in a similar manner as 
that proposed for Standard ML in [17]. The operator t • T promotes the type T to the kind t. It is defined 
by t • (t'( 7,C)) = T • (7 ,C) and by t- (A(x : S).T) — A(x : S).(t-T). It is used to check that the definition 
of a module type is a contract and to promote the type of a module. 

r/E I ~s :S r/E b t : T T/E b j : S T/E h t : T T/E b t : T Y/Y.\~dec:l T/E b dec 1 : J 
YfLY s x t : S x T T/E b A(x : s).t : A(x : S).T T/E b t x : (x : T) T/E b dec, dec' : 7 U 7 

r/E b p r/Ebf/ T/E b qg : C Y/LYag'-.D r/Ebx : y(x i : 7j..x„ : T n ,C ) (r(y ; ) < 7])[L| 

T/E b assume p guarantee q : {p,q) T/Ebagandag' : CJJ75 Y /"LY x(y\,,„) : C[v,/x ( ]/ =1 

T/E b dec : 7 TU7bag:C T/E b dec: 7 YlilYp T/Ebexp:S r/Ebexp':T 

T/E b contractdec;flgend : y(7,C) I ’/E I process dec. p end : n(I ,i().p)) r/E b {exp and exp') : S bl 7' 
r(x) = T T/E b dec : I TU7/Eb exp : T r/Ebx: A(z : S).T Y/LYy:U LcU<S 
r/Ebx: T T/E b functor (dec) exp end : A7.T T/E b x(y) : T[y/z] 

T/E b exp : T y-T <T T/E b exp: S’ T/Ebf:T E C S < T T/Ebde/:7 TU7/Ebexp:T 

T/E b module typex = exp : (x : T) I ’/E b modulex : t — exp : (x : 71 ■ T) f/Eb letde/in exp : T 
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4.7 Correctness 

The correctness of our module system is stated by showing that a program is well-typed if the constraints 
implied by T /£ are consistent. We say that the environment p is well-typed with V /£, written p : V /£, 
iff all definitions in p are well-typed with T under the constraints £. Notice that, in this implementation 
of the type system, the generated constraints £ define the proof obligations that are needed for checking 
that the specification exp is well-typed. To establish this theorem we define the semantics [[exp]] p of a 
term exp in the module system by induction on the structure of exp. It is a set of processes p of the model 
of computation that satisfy their specifications. 

Theorem 1. If p : T /'Lfor a satisfiable £ and T/£ b exp : T then [[exp]] p C [[T]] p . 

Proof sketch The proof of Theorem 1 is by induction on the structure of expressions exp (just as for a 
regular type system). For each syntactic category in the grammar of exp , it considers a satisfiable set of 
constraints £, a well-typed environment p : T/£ and assumes a proof tree for T/£ h exp : T . Induction 
hypotheses are made to assert that the sub-expressions expi e i..„ of exp satisfy the expected sub-goals 
[[exp,-]] p C [[Tj]}p in order to deduce that [[<?xp]] p C [[T]] p by definition of the denotational semantics. 

5 Discussion 

We illustrate the distinctive features of our contract algebra by reconsidering the specification of the 
four-stroke engine and its translation into observers in the target language of our choice: the multi- 
clocked synchronous (or polychronous) data-flow language Signal [7]. The separation of environmental 
assumptions and system guarantees is facilitated by the (unpaired) possibility to naturally express the 
complementary of a process-filter. Had we used automata to model A/„ ra fe, as in most of the related work, 
it would probably have been more difficult to model the engine not being in the intake mode: this would 
have required the definition of the complementary of an automaton and, most importantly, this could 
not have been done compositionaly. In our algebra, the complementary of the intake property is simply 
defined by A i nta k e — cam modulo 360° > 90. In general, the generic structure of observers specified in 
contracts will find a direct instance and compositional translation into the synchronous multi-clocked 
model of computation of Signal [16]. Indeed, a subtlety of the Signal language is that an observer not 
only talks about the value, true or false, of a signal, but also about its status, present or absent. Thanks to 
its encoding in three-valuated logic, an event (e.g. intake is present and true) can directly be associated 
with its complementary (e.g. intake is absent or false) without separating the status (the clock) and the 
value (the stream). Hence, the signal A nnu i ie is present and true iff cam signal is present and its value is 
between 0 and 89 degrees. 

A intake — 1 rue when (0 < cam modulo 360 < 90) G i nta ke = ( true when intake) default false 

The complementary of these assumptions is simply defined to be true iff the cam is absent or out of 
bounds: A i nta k e — ( false when Ai nta k e ) default true. Notice that, for a trace of the assumptions A intake, 
the set of possible traces corresponding to A [ nta k e is infinite (and dense) since it is not defined on the 
same clock as A i nta k e . 

^intake = 1-0_1_0_1_0_1_0_1_ and A^ = 0___0___0___0___0_ or 01 1 101 1.01. 10..101 ... 

It is also worth noticing that the clock of A i„ ta k e (its reference in time) need not be explicitly related to or 
ordered with A Inta k e or G i nta ke- it implicitly and partially relates to the cam clock. Had we used a stricly 
synchronous model of computation, as in [18], it would have been necessary to know the clock of the 
system in order to define that of the complementary by a sample of it. Beside its Boolean structure, which 
allows for logical reasoning and normalization of contracts, our algebra supports the capability to com- 
positionally refine contracts. For instance, consider a more precise model of the 4-stroke engine found 
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in [4]. To additionally require the engine to reach the EC state (Exhaust closes) between 5 and 20 degrees, 
while in the intake mode, one will simply compose the initial contract with an additional constraint with 
: A ec — true when (5 <= cam modulo 360 < 21) and Gec — true when EC default false. Similarly, 
event OTDC (Overlap Top Dead Center) occurs at the beginning of the cycle. The instant toTDC is a 
time observation of this event and the occurrence of the event EC is constrained by {toTDC + [5.. 20]}, 
hence toTDC + 5 < trc < Urmc + 20. We shall refine the specification of the engine to incorporate these 
additional constraints. This is done as follows: 

module type better_engine = engine 


intake 

Compression 

Combustion 

Exhaust 


@tfBDC -v. 


@toTDC 

FB 

IC 

DC 


I . { toTDC + [5..20] } 

lr 
! EC 


1 { tsBDc - [45..60] } 

! \J 

ITDC I— 


c \i 

OTDC 


and contract 

input integer CAM ; 

output event EC, IC, EO, 10; 

phase (5,20) (CAM, EC) 
and phase (130, 150) (CAM, IC) 
and phase (2 10 , 225 ) (CAM,EO) 
and phase (344, 350) (CAM, 10) 


end; 

It is needless to say that a sophisticated solver, based for instance on Pressburger arithmetics, shall help 
us to verify the consistency of the above engine map. Nonetheless, an implementation of the above en- 
gine specification, for the purpose of simulation, can straightforwardly be derived. As a by-product, it 
defines an observer which may be used as a proof obligation against an effective implementation of the 
engine controller to verify that it implements the expected engine map. Alternatively, it may be used as a 
medium to synthesize a controller enforcing the satisfaction of the specified property on the implemen- 
tation of the model. In Signal, process phase consists of one equation that is executed when its output 
trigger is needed (its clock is active). If the signal cam is present and within the specified bounds 
min-max, then trigger is present. Otherwise, cam is absent or simply out of bounds, the trigger is 
absent. The signals cam and trigger are respectively the input and output of the process whereas the 
names min-max are functor parameters of the process. 


process phase = {integer min, max;} (? integer cam; ! event trigger;) 

(| trigger := when min<= (cam mod 360)<max |); 


In the process engine, four instances of the phase equation are defined to specify the output signals 
that are relevant to a specific phase of the engine. Notice that these signals are not, a priori , synchro- 
nized one with the other: they are concurrent. This is done to favor a compositional specification of 
the system. Refinement precisely allows to iteratively build a sequentially executable specification by, 
e.g., synchronizing the signals OTD, FBD, ITD and SBD. This choice in favor of compositional model- 
ing (polychrony) versus executability (synchrony) allows us to handle the additional specification of the 
better engine in a compositional manner, showing that the Signal language and our module system share 
the same concurrent/compositional design philosophy. 


process engine = 
(? integer CAM; 

! event OTD 

, FBD 

( | OTD 

:= phase 

{ 0, 

90} 

(CAM) 

| FBD 

:= phase 

{ 90, 

180} 

(CAM) 

| ITD 

:= phase 

{180, 

270} 

(CAM) 

| SBD 

:= phase 

{270, 

360} 

(CAM) 


) ; 


process betterengine = 

(? boolean CAM ! event OTDC, FBDC, ITDC, ... 
(I (OTDC, FBDC, ITDC, SBDC) := engine (CAM) 

I EC ;= phase { 5, 20} (CAM) 

I IC := phase {130, 150} (CAM) 

I EO := phase {210, 225} (CAM) 

I 10 := phase {344, 350} (CAM) ); 


Contracts can be used to express exclusion properties. For instance, when the engine is in the intake 
mode, one should not start compression. We have A exc i—OTDC and G exc i—^FBDC. 


module type exclude = contract output event intake, compression; 

assume intake guarantee (not compression default intake) 
end; 


In addition to the above safety properties, contracts can also be used to express liveness properties. For 
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instance, consider the protocol for starting the engine. A battery is used to initiate its rotation. When 
the engine has successfully started, the battery can be turned off. We define a contract to guarantee that 
when the ignit button is pushed, the starter eventually stops. 

module type StarterOff = contract input event ignit; output boolean starter; 

assume ignit guarantee eventually not starter 
end; 

6 Implementation 

The module system described in this paper, embedding data-flow equations defined in syntax, has been 
implemented in Java. It produces a proof tree that consists of 1/ an elaborated Signal program, that 
hierarchically renders the structure of the system described in the original module expressions, 2/ a static 
type assignment, that is sound and complete with respect to the module type inference system, 3/ a proof 
obligation consisting of refinement constraints, that are compiled as an observer or a temporal property 
in Signal. 

The property is then tended to Signal’s model-checker, Sigali [20], which allows to prove or dis- 
prove that it is satisfied by the generated program. Satisfaction implies that the type assignment and 
produced Signal program are correct with the initially intended specification. The generated property 
may however be used for other purposes. One is to use the controller synthesis services of Sigali [19] to 
automatically generate a Signal program that enforces the property on the generated program. Another, 
in the case of infinite state system (e.g. on numbers) would be to generate defensive simulation code in 
order to produce a trace if the property is violated. 

7 Related work 

The use of contracts has been advocated for a long time in computer science [21, 13] and, more recently, 
has been successfully applied in object-oriented software engineering [22]. In object-oriented program- 
ming, the basic idea of design-by-contract is to consider the services provided by a class as a contract 
between the class and its caller. The contract is composed of two parts: requirements made by the class 
upon its caller and promises made by the class to its caller. The assumption specifies hypothesis which 
has to be satisfied by the component in order to provide the guarantee. 

In the context of software engineering, the notion of assertion-based contract has been adapted for 
a wide variety of languages and formalisms but the central notion of time and/or trace needed for re- 
active system design is not always taken into account. For instance, extensions of OCL with linear or 
branching-time temporal logics have been proposed in [25, 10], focusing on the expressivity of the pro- 
posed constraint language (the way constraints may talk about the internals of classes and objects), and 
considering a fixed “sequence of states”. This is a serious limitation for concurrent system design, as this 
sequence becomes an interleaving of that of individual objects. 

In the theory of interface automata [1], the notion of interface offers benefits similar to our notion of 
contracts and for the purpose of checking interface compatibility between reactive modules. In that con- 
text, it is irrelevant to separate the assumptions from guarantees and only one contract needs to be and is 
associated with a module Separation and multiple views become of importance in a more general-purpose 
software engineering context. Separation allows more flexibility in finding (contra- variant) compatibility 
relations between components. Multiple views allow better isolation between modules and hence favor 
compositionality. In our contract algebra as in interface automata, a contract can be expressed with only 
one filter. To this end, the filtering equivalence relation (that defines the equivalence class of contracts 
that accept the same set of processes) may be used to express a contract with only one guarantee filter 
and with its hypothesis filter accepting all the processes (or, conversely, with only one hypothesis filter 
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and a guarantee filter that accepts no process). 

In the context of the EC project Speeds [6], a model of assume-guarantee contracts is proposed which 
extends the notion of interface automata with modalities and multiple views. This consists of labelling 
transitions that may be fired and other that must. By contrast to our domain-theoretical approach, the 
Speeds approach starts from an abstracted notion of modules whose only structure is a partial order of 
refinement. The proposed approach also leaves the role of variables in contracts unspecified, at the cost 
of some algebraic relations such as inclusion. 

In [18], a notion of synchronous contracts is proposed for the programming language Lustre. In 
this approach, contracts are executable specifications (synchronous observers) timely paced by a clock 
(the clock of the system). This yields an approach which is satisfactory to verify safety properties of 
individual modules (which have a clock) but can hardly scale to the modeling of globally asynchronous 
architectures (which have multiple clocks). 

In [8], a compositonal notion of refinement is proposed for a stream-processing data-flow language. 
The proposed type system allows reasoning on properties of programs abstracted by input-output types 
and causality graphs. In a similar way as Broy et al., we aim at using our module system to associate 
programs with compilation contracts, consisting of the necessary (and sufficient) synchronization and 
scheduling relations for modular code generation. 

The system Jass [5] is somewhat closer to our motivations and solution. It proposes a notion of trace, 
and a language to talk about traces. However, it seems that it evolves mainly towards debugging and 
defensive code generation. For embedded systems, we prefer to use contracts for validating composition 
and hope to use formal tools once we have a dedicated language for contracts. Like in JML [15], the 
notion of agent with inputs/outputs does not exist in JASS, the language is based on class invariants, and 
pre/post-conditions associated with methods. 

Another example is the language Synergy [9], that combines two paradigms: object-oriented model- 
ing for robust and flexible design, and synchronous execution for precise modeling of reactive behavior. 
In [14], a method of encapsulation based on the object-oriented paradigm and behavioral inheritance for 
the description of synchronous models is proposed. [24] describes an ML-like model for decomposing 
complex synchronous structures in parameterizable modules. 

Our main contribution is to define a type system starting from a domain theoretical algebra for 
assume-guarantee reasoning consisting of a Boolean algebra of process-filters and a Heyting algebra 
of contracts. This yields a rich structure which is 

1/ generic, in the way it can be implemented or instantiated to specific models of computation; 

2/ flexible, in the way it can help structuring and normalizing expressions; 

3/ complete, in the sense that all combinations of propositions can be expressed within the model. 

Finally, a temporal logic that is consistent with our model, such as for instance the ATL (Alternating- 
time Temporal Logic [3]) can directly be used to express assumptions about the context of a process and 
guarantees provided by that process. 


8 Conclusion 

Starting from an abstract characterization of behaviors as functions from variables to a domain of values 
(Booleans, integers, series, sets of tagged values, continuous functions), we introduced the notion of 
process-filters to formally characterize the logical device that filters behaviors from process much like 
the assumption and guarantee of a contract do. In our model, a process p fulfils its requirements (or 
satisfies) (A,G) if either it is rejected by A (i.e., if A represents assumptions on the environment, they 
are not satisfied for p ) or it is accepted by G. The structure of process-filters is a Boolean algebra and 
allows for reasoning on contracts with great flexibility to abstract, refine and combine them. In addition 
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to that, and unlike the related work, the negation of a contract can formally be expressed from within 
the model. Moreover, contracts are not limited to expressing safety properties, as is the case in most 
related frameworks, but encompass the expression of liveness properties. This is all again due to the 
central notion of process-filter. We introduced a module system based on the paradigm of contract for a 
synchronous multi-clocked formalism, Signal, and applied it to the specification of a component-based 
design process. The paradigm we are putting forward is to regard a contract as the behavioral type of 
a component and to use it for the elaboration of the functional architecture of a system together with a 
proof obligation that validates the correctness of assumptions and guarantees made while constructing 
that architecture. 
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